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Requirements" Importance of Requirements 

Link: 

http://www.dilbert.com/strips/comic/2006-01-29/ http://www.projectsmart.co.uk/docs/chaos-report.pdf 


Reason for Project Failure 

% of 

Responses 

Incomplete requirements 

13.1 

Lack of user involvement 

12.4 

Lack of resources 

10.6 

Unrealistic expectations 

9.9 

Lack of management support 

9.3 

Changing requirements 

8.7 

Lack of planning 

8.1 

System no longer needed 

7.5 
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Requirements 

Types: 

user requirements 

• what tasks the user can do with the system 

functional requirements (features) 

• what behaviors the system does or supports 

non-functional requirements (qualities) 

■ how well the system should do what it does 

• e.g. : response time, resource usage, availability 


Requirements 

Types: 

business requirements 

• why the system is needed 

business constraint 

• what the system or process must comply with 

• e.g., corporate policy, industry standard, 
government regulation 


Requirements 

Types: 

external interfaces 

• e.g., interfaces to other hardware and software, 
data sources and sinks, formats, protocols 

physical setting 

• e.g., location, workspace, lighting, noise, temperatu 
developer constraint 

• e.g., implementation technology, documentation 


Requirements 

Requirements should be: 
correct 

• requirements properly represent user needs 
complete 

• all possible scenarios are described 
consistent 

• requirements do not contradict each other 

clear 

• no ambiguities 

realistic 

• can be achieved by "mere mortals" 


Requirements 

Verifiable Requirements 

Also desired: 
traceable 

Verifiable? 

■ can trace functionality and tests to the 
requirement being satisfied 

"The system shall have a good user interface." 

verifiable 


• repeatable test(s) can be designed to show that 
the system fulfills the requirement 
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Verifiable Requirements 

Verifiable Requirements 

Verifiable? 

Verifiable? 

"The system shall respond to the user in under one second 
for most tasks." 

"When the output state changes, it is logged in the event 
log." 
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Verifiable Requirements 

Verifiable? 

"The system shall be free of defects." 


Requirements Activities 

Done iteratively: 

requirements elicitation 

• discover user needs 

requirements analysis 

• decide scope and priorities 

• study feasibility, create mockups 

requirements specification 

• detail the requirements in terms the users can 
understand 


13 


14 


Users 

Who is the "user"? 
primary 

• end user 

• with frequent hands-on use 
secondary 

• manager of end users 

• with occasional use, or via an assistant 

tertiary 

• owner of the system 

• uses output, influences or makes funding decisions 


Users 

Some characteristics to consider: 
background 

• literacy and language 

• motivation to learn 

• domain knowledge 

• task familiarity 

• computer skills 

• attitude to computers and technology 
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Users 


Some characteristics to consider: 

perceptual, motor, and tactile abilities 

• seeing and hearing difficulties 

• fine motor skills with input devices 

physical 

• height and strength (for kiosk design) 

• hand/finger size (for mobile device design) 

• health, age, and gender 

social 

• relationships with peers 

• culture 
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Users 

Kinds of use: 

infrequent use / novice user 

• need wizards 

• need clear prompts, error handling 

frequent use / expert user 

• need keyboard shortcuts 

■ need customization, programmability 


Users 

Some issues to consider: 

users cannot always express what they want 

• but they often know what they do not like 
users may not know what is possible 

• what is technically and economically feasible? 
users stick to what they ... 

• know already works, or have always done 
users may fear job losses 

• leads to non-constructive participation 
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// 


Users" 


Users 


"Innovator's dilemma": 

http://www.dilbert.com/strips/comic/1994-09-22/ as the user base for an application grows, there is a 

tendency for developers to focus on this increasingly 
expert (and vocal) group of users 


the system becomes more sophisticated 
development becomes "optimized" for them 
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Users "Listening to Users" 

"Innovator's dilemma": 

potential new users need "less" 

experts don’t want their app "dumbed down" 


competitor attracts the new users with a simpler "good 
enough” app 


original app loses market share due to disruption from the 
low end 
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"Listening to Users" 

http://theoatmeal.com/comics/design_hell 
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User Requirements 


Understanding 

Tips: 

manage expectations 

• be clear and honest about claims 

• avoid surprises, disappointments, hype 
involve the user 

• build tangible prototypes to gain feedback 

• more likely to forgive problems if they are 
involved 

establish a glossary 

• terminology used in the application domain 
(not programming domain) 
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Identifying Tasks 

Study what tasks users do: 

what is the goal and context? 
what information is needed? 
what are the steps? 
who does the user work with? 
why is it done this way? 
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Identifying Tasks 

Scenario: 

an informal narrative 

personal and concrete, but not particularly general 

use the scenario to understand existing goals, task flow, 
and possible irritants 
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Specifying Tasks 

Use Cases: 

capture the goal, conditions, and steps of a coherent 
interaction between the actor(s) and the software system 


more general than a specific scenario 


written from a "user" point-of-view 


Scenario 

Example: 

"I want to track the calories for a meal, so I consult the 
USDA Nutrient database. I want to look up 'Pacific salmon’ 
so I enter that as the keywords. Item not found! So I enter 
'salmon' and try again. That works, but I get 46 items, 
including salmonberries and even cloudberries. Why? I 
choose 'fish, salmon, sockeye, cooked, dry heat’, then 
figure 2.5 x 100 g units for my item, and scan the table to 
see 422 kcal in the energy row." 
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Defining Use Cases 

Stages: 

identify the actors 

• consider different user roles and external systems 
define use cases 

• include all cases of use 
refine use cases 

• consider exceptional conditions and qualities 
relate use cases 

• consider inclusion and extension dependencies 


31 


32 


Identify the Actors 


Identify the Actors 


use case diagram 



Actor generalization: 


User 



Meal Administrator 

Planner 
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Define/Refine Use Cases 

Example: 

Use Case Name 
Participating Actors 
Goal 
Trigger 
Precondition 
Postcondition 


Define/Refine Use Cases 

Example. user point of view 

Basic Flow 1 
2 

3 

4 

5 

6 
7 


SearchForNutritionlnfo 

Meal Planner (primary) 

Meal Planner finds nutrition information 

Meal Planner chooses the Search option 

Meal Planner knows food name and 
amount. 

On success, nutrition information displayed. 


System prompts Meal Planner to enter 
keywords. 

Meal Planner submits keywords. 

System lists matching foods, prompting for 
a selection. 

Meal Planner browses and selects a food. 
System prompts for food weight in units of 
100 g. 

Meal Planner enters food units. 

System presents nutrition data for the 
amount of food. 

avoid implementation specifics 
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Define/Refine Use Cases 


Define/Refine Use Cases 


Example: 


Example: 


Exceptions 3 

3.1 

3.2 
7 


If there are no matching foods 
System displays an error 
System returns to step 1 

If given food units is non-numeric, use 0 
and proceed 


Qualities 

Constraints 
Includes 
Extends 
Related Artifacts 
Notes 
Open Issues 


System responds in under 2 s for list of 
matching foods and for nutrition data on a 
specific food. 

Use USDA nutrition data. 
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Essential Use Case 


Exercise 


SearchForNutritionlnfo 


User Intention (Meal 

Planner) 

System Responsibility 

Initiate search. 



Request keywords. 

Submit keywords. 



List matching foods to 
select. 

Select a food. 



Request food units. 

Enter food units. 



Present nutrition data. 


Question: 

What is a basic flow for the task of 
withdrawing cash from a bank machine? 
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Relate Use Cases 


Relate Use Cases 


Inclusion: 

a use case may include another use case 
(for necessary, shared behavior) 


Extension: 

a use case may be extended by another use case (for 
optional or exceptional behavior) 



Relate Use Cases 

Use case generalization: 

a use case may be a specialization of a more general use 
case 


User Stories 
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Specifying Needs 


Write down all the 
requirements. 


Users only get what 
was written. 


Agile method: less writing, more talking 


Users get what 
they want. 
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Specifying Needs 

User story: 

written description of what a user wants to achieve with 
the system 


As a guest, I want to 
reserve a hotel room. 

r7sa~guestTwant to see 
| a list of room amenities. 

As a conference planner, 

- I want to see meeting 
room capacities. 


on index cards 


Typical forms: 

As a «user roie», 
I want «goal». 

As a «user roie», 
I want «goal», 
so that «reason». 
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Defining User Stories 

Tips: 

describe what not how 

• avoid technical details or choices of 
technologies, 

unless it is a development constraint 


avoid epics for near-term needs 

• better to split up huge stories into more, 
smaller stories (but not too small) 


Defining User Stories 

Tips: 

prioritize user stories 

• discuss with the user what they find of most 
value, and stage development on that first 


can attach an effort estimate to complete 

• normally sized to take days, not many weeks 


use stories to plan development tasks 

• create work items in the iteration plan 
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"SMART Work Items" 


s 

Specific 

M 

Measurable 

A 

Achievable 

R 

Relevant 

T 

Time Boxed 


"INVEST in Good Stories" 


I 

Independent 

N 

Negotiable 

V 

Valuable 

E 

Estimable 

S 

Small 

T 

Testable 


Link: 

http://xpl23.com/articles/invest-in-good-stories-and-smart-tasks/ 


Link: 

http://xpl23.com/articles/invest-in-good-stories-and-smart-tasks/ 
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Testable User Stories Testable User Stories 


Front of the card: 


Back of the card: 


As a meal planner, I want 
to see nutrition 
information for a given 
amount of a given food. 


Link: 

http://xprogramming.com/articles/ 

expcardconversationconfirmation/ 


acceptance tests 


Try it for 250 g of 
I ^. aked Pacific salmon. 
Try it with a missing 
food name. 

Try it with a non- 
numeric amount. 
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"User Story" 

http://www.dilbert.corn/strips/comic/2003-01-10/ 

Augmenting 

Requirements 
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Augmenting Requirements State Models 

Can add other descriptions, for example: Modeling behavior: 

use cases to user stories used in formally modeling the behavior of a specific object 

in response to external events 

data schemas 

sample input and output 

user interface mockups and storyboards 

grammars (language syntactic/lexical structure) 


identifier 


->f letter 


letter 




<identifier> : : = 

<letter> { <letter> | <digit> } 

-> 


digit 
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UML State Diagram 

Modeling behavior: 

states in which something can be in 

■ a situation represented by attribute values 

directed transitions between states 

• triggered by events, input, time, messages, etc. 


start / toggle := true 



transition 

' 

On 


initial state 


state 


stop / toggle : = false 


UML State Diagram 



UML State Diagram 

States: 


UML State Diagram 

Activities in states: 


state name 


r 


\ 


state name 



activities 


\ 


/ 


( \ 

state name 


variables 


activities 

\ _ ) 


entry / 
action 

perform action when entering 
state 

do / action 

perform action while in state 

exit / action 

perform action when exiting 
state 



Timing 

timeout 

Ready 


do / countdown 


entry / beep 


\ _V_/ 
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UML State Diagram UML State Diagram 


Activities in states: also called an 

internal transition 



Transitions: 


general form of transition label 


trigger [ guard ] / effect 


if in a current state, 
and trigger occurs, 

and guard constraint (if any) is true ... 


then perform state exit actions (if any), 
perform corresponding transition effect (if any), 
perform new state entry actions (if any); 


otherwise, stay at current state 
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Room Planner 

Canvas: 

to place and move items 


Mouse events: 
click 


press/drag/release 


Item type menu: 

choices of fixtures and turn 




X 

o 





Room Planner 


Placing an item: 

user clicks on canvas outside any item 

• system shows the item type menu 
user chooses an item type from the menu 

• system hides the item type menu 
user clicks on the canvas 

• system draws item of the chosen type 
at the mouse location 
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Room Planner 

Room 

Planner 

Moving an item: 

States: 


user presses inside an item 

waiting 


■ system highlights item 

• 

nothing happening 

user drags item 

moving 


• system shows moving item 

• 

moving item to new position 

user releases mouse 

choosing 


• system puts item at new location 

• 

choosing item type from menu 

• system removes item highlighting 

placing 



• 

placing chosen shape 
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click 

[outside any item] / 
show menu 
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UML State Diagram 

Tips: 

check for completeness 

• states reachable? 

• missing transitions? 

• events not considered? 

• unforeseen situations? 

check for dangerous situations 

• e.g., exiting without having saved edits 


drag (x, y) 
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UML State Diagram 

Tips: 

check for consistency 

■ similar interactions have similar effects? 

• effects are visible and give good feedback? 

aid the user 

• is undo appropriate, in a given state? 

■ is cancel or escape appropriate? 

■ is invoking help appropriate? 


More Information 

Books: 

The Essence of Object-Oriented Programming with Java 
and UML 

• B. Wampler 

• Addison-Wesley, 2002 

UML Distilled 

• M. Fowler 

• Addison-Wesley, 2003 
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More Information 

Books: 

User Stories Applied 

• M. Cohn 

• Addison-Wesley, 2004 

More About Software Requirements 

• K. Wiegers 

■ Microsoft, 2006 


More Information 

Books: 

Software Engineering: Theory and Practice 

• S.L. Pfleeger 

• Prentice-Hall, 2009 
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More Information 

Links: 

Use Cases, Ten Years Later 

■ http://alistair.cockburn.us/Use+cases%2c+ten+yec 
later 


Effective User Stories for Agile Requirements 

• http://www.mountaingoatsoftware.com 

/presentations/52-effective-user-stories-for-agile-re' 


